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REMARKS 

The foregoing amendments are responsive to the November 16, 2005 Office Action. 
Applicants respectfully request reconsideration of the present application in view of the 
foregoing amendments and the following remarks. 

Please charge any additional fees, including any fees for additional extension of time, or 
credit overpayment to Deposit Account No. 11-1410. 

Response to Rejection of Claims 1-27 Under 35 U.S.C. 103(a) 

The Examiner rejected Claims 1-27 under 35 U.S.C. 103(a) as being unpatentable over 
Beydaet al., ("Beyda") U.S. Patent No. 5,935,218 and further in view of Ratner et al. ("Ratner"), 
U.S. Patent No. 5,684,826. Beyda teaches an Ethernet-type network where all nodes have equal 
right to access the network (see column 2 at lines 50-51). By contrast, Claim 1 recites a token- 
based system wherein all nodes do not have equal right to access the network. The server 
arbitrates access by passing the token to a node. The node returns access by returning the token to 
the server. 

Beyda teaches that low priority users receive a delay message that instructs them to wait 
for a time period equal to the delay before using the network resource (see column 3 at lines 14- 
16). Thus, the message sent by Beyda is a message instructing the low-priority node to minimize 
its use of the network. This is in contrast to a token-based system, where the token is an 
invitation to use the network. Thus, Beyda does not teach or suggest token packet from an active 
server to a first client node, and sending an end of token session packet. 

Ratner teaches buffering data in a processor. Ratner does not teach or suggest arbitration 
of access other than to mention the RS-485 standard. In RS-485, collisions are typically found 
only by receiving a corrupted message. Thus, Ranter does not teach or suggest arbitration by 
token passing or waiting for a period of time after an end of token session packet to allow a node 
to send a lineup insertion packet. 

As shown in Figure 2, Beyda does not teach or suggest sending an end of token session 
packet from the first client to the server and waiting for a prescribed time period to allow a 
second client node to send a lineup insertion packet to the active server, as recited in Claim 1. 
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Beyda does not teach or suggest any type of end-of-session indicator. In Beyda the node simply 
stops transmitting. 

Regarding Claim 1, the cited combination does not teach or suggest network 
access arbitration by sending a token packet from an active server to a first client node, the token 
packet granting bus access to the first client node, sending an end of token session packet from 
the first client to the server, the end of token session packet relinquishing bus access by the first 
client node, and waiting for a prescribed time period after receipt of the end of token session 
packet to allow a second client node to send a lineup insertion packet to the active server. 

Regarding Claim 2, the cited combination does not teach or suggest the method of 
Claim 1, wherein the active network server maintains a lineup card that lists one or more client 
nodes. 

Regarding Claim 3, the cited combination does not teach or suggest the method of 
Claim 1 , wherein the token packet specifies a maximum number of packets that the first client 
can send before sending the end of token session packet. 

Regarding Claim 4, the cited combination does not teach or suggest the method of 
Claim 3, wherein the first client node is allowed to transmit data packets on the network medium 
only during a token session. 

Regarding Claim 5, the cited combination does not teach or suggest the method of 
Claim 3, wherein the first client node is removed from the lineup card when the node has been 
inactive for a period of time. 

Regarding Claim 6, the cited combination does not teach or suggest the method of 
Claim 3, wherein the lineup insertion packet requests insertion onto a high priority queue. 

Regarding Claim 7, the cited combination does not teach or suggest the method of 
Claim 1, wherein a presence of a packet is detected by matching a specified preamble and length 
sequence. 

Regarding Claim 8, the cited combination does not teach or suggest the method of 
Claim 1, wherein access to the medium is provided by a media access control layer. 

Regarding Claim 9, the cited combination does not teach or suggest the method of 
Claim 8, wherein the media access control layer provides a burst mode. 
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Regarding Claim 10, the cited combination does not teach or suggest the method 
of Claim 1, wherein the medium provides multiple channels. 

Regarding Claim 11, the cited combination does not teach or suggest the method 
of Claim 1, wherein the medium is a power line. 

Regarding Claim 12, the cited combination does not teach or suggest the method 
of Claim 1, wherein the medium is a radio frequency transmission medium. 

Regarding Claim 13, an active server node, and at least one client node, the active 
server node configured to provide a token to the at least one client node, the at least one client 
node configured to transmit on the medium for no more than a specified time period before 
sending an end of token session packet to the active server node. 

Regarding Claim 14, the cited combination does not teach or suggest the network 
architecture of Claim 13, wherein the active server node maintains a lineup card of active client 
nodes, the lineup card comprising a high priority queue and a low priority queue. 

Regarding Claim 15, the cited combination does not teach or suggest the network 
architecture of Claim 13, wherein the active server node polls all nodes listed on the high priority 
queue before polling a next node listed on the low priority queue. 

Regarding Claim 16, the cited combination does not teach or suggest obtaining a 
plurality of data packets in a source node, transmitting the data packets, one data packet per 
channel, to a destination node, receiving a multi-channel acknowledgement from the destination 
node, the multi-channel acknowledgement transmitted on substantially all of the channels, the 
multi-channel acknowledgement providing acknowledgement information for each of the 
channels. Neither Beyda nor Ratner teaches a multi-channel system. 

Regarding Claim 17, the cited combination does not teach or suggest a multi- 
channel network medium, active server means fro maintaining a list of active client nodes and 
arbitrating access to the medium, the active server means providing a token, 

Regarding Claim 18, the cited combination does not teach or suggest the data 
network of Claim 17, wherein the client node means comprises a multi-channel receiver. 

Regarding Claim 19, the cited combination does not teach or suggest the data 
network of Claim 17, wherein the client node means comprises a single-channel receiver. 
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Regarding Claim 20, the cited combination does not teach or suggest the data 
network of Claim 17, further comprising burst mode means for sending unacknowledged data. 

Regarding Claim 21, the cited combination does not teach or suggest the data 
network of Claim 1 7, wherein the network medium comprises a power line. 

Regarding Claim 22, the cited combination does not teach or suggest the data 
network of Claim 17, wherein the network medium comprises a radio frequency link. 

Regarding Claim 23, the cited combination does not teach or suggest the data 
network of Claim 17, wherein each of the active server prioritizes a plurality of client node 
means. 

Regarding Claim 24, the cited combination does not teach or suggest sending a 
plurality of fragments to a destination node, receiving a response indicating which of plurality of 
the fragments were received and which of the plurality of the fragments that were lost; and 
resending with fragments that were lost. 

Regarding Claim 25, the cited combination does not teach or suggest a processor, 
a memory operatively coupled to the processor; and a protocol program loaded in the memory, 
the program configured to receive a token from a server node, the token specifying a maximum 
number of data packets, hold the token, transmit data packets on the network while holding each 
token; and return the token to the server node after sending the specified maximum number of 
data packets. 

Regarding Claim 26, the cited combination does not teach or suggest the network 
node of Claim 25, wherein the network medium is a power line medium and the network node 
provides streaming data across the power line medium. 

Regarding Claim 27, the cited combination does not teach or suggest the network node of 
Claim 26, wherein the multimedia data comprises voice data. 

Accordingly, Applicants assert that Claims 1-27 are patentable over the prior art, and 
Applicants request allowance of Claims 1-17. 

Request for Interview 

Applicant hereby requests a telephone interview with the Examiner to discuss this 
application. The attorney of record can be reached at (949) 721-6305. 
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Summary 

Applicants respectfully assert that Claims 1-27 are in condition for allowance, and 
Applicants request allowance of Claims 1-27. If there are any remaining issues that can be 
resolved by a telephone conference, the Examiner is invited to call the undersigned attorney at 
(949) 721-6305 or at the number listed below. 

Respectfully submitted, 



Dated: February 16, 2006 



KNOBBE, MARTENS, OLSON & BEAR, LLP 



By: 



Lee W. Henderson Ph.D. 
Registration No. 41,830 
Atttorney of Record 
Customer No. 20,995 
(949) 760-0404 
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